https://www.dynamisys.co.uk RSS feeds for Dynamisys 60 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/115/DNN--Why-is-lucene-throwing-LockObtainFailedException#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=115 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=115&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/115/DNN--Why-is-lucene-throwing-LockObtainFailedException I found that my site did not allow lucene write permissions. I also deleted everything in App_Data\Search - allows lucene to recreate it, and cycled the App Pool. The Exceptions went away. RichardHowells Fri, 28 Feb 2020 10:43:00 GMT f1397696-738c-4295-afcd-943feb885714:115 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/88/Why-Cant-I-Connect-to-my-SQL-Server-Database--1--Using-SQL-Server-Security#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=88 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=88&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/88/Why-Cant-I-Connect-to-my-SQL-Server-Database--1--Using-SQL-Server-Security Sadly I cannot just give you the answer to this one.  You'll have to do some diagnosis yourself.  This is a basic guide to find out where the blockage lies. What is SQL Server Security? This is when you have a user id and password visible in the connection string.  So the connection string would look like... Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername; Password=myPassword; Notes: The server name may be specified as a single dot ('.') to mean 'same machine as I am connecting from'.  Instance name is only used if you have installed SQL server as a named instance.  Some do, some don't.  The default is no named instance for 'full' SQL Server, and sqlexpress for SQL Server express. 2. Can you connect from the server? Install SQL Server Management Express (SSME) on the machine that hosts the database.  Can you connect from SSME using the id and password which you believe to be valid for the database.  If you can't then you need to find out why and fix it. 3. Can you connect from the client? Install SQL Server Management Express on the machine (the client) that you want to connect from.  Can you connect to the remote server and database?  Use the id and the password that Step 2 proved would work.  If you can't then you know that there is a problem in the connectivity.  Things to try: can you ping the server from the client (this may not be conclusive as the server may have ping responses turned off) research the connection path between the client and the the server.  Do any firewalls or other network devices allow SQL server traffic to pass?  This is usually TCP port 1433 for normal queries and responses.  Whomever manages that SQL Server may have adjusted the port it listens on, but that is quite rare.  SQL Server also has other ports it uses for other purposes. does the server have a firewall?  Does it allow SQL server traffic in? does the server SQL instance allow remote connections? does it allow remote connections on the protocol stack you plan to use?  Usually TCP/IP. do you have the TCP/IP (or whatever you plan to use) support installed? 3. If you can pass all the checks above then I'm out of ideas for the moment.  Feel free to add a comment if you have any additional things to try.     RichardHowells Thu, 02 Jun 2016 13:46:00 GMT f1397696-738c-4295-afcd-943feb885714:88 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/87/Three-Killer-Reasons-why-you-should-NOT-be-building-DNN-in-Visual-Studio-or-any-other-tool#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=87 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=87&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/87/Three-Killer-Reasons-why-you-should-NOT-be-building-DNN-in-Visual-Studio-or-any-other-tool It's not necessary to build DNN from source code.  Avoid a lot of pain, ignore the 'source' packages, install the 'install' package.  Here's why: 1 if you just want a web site then DNN is already a great solution.  Go to the site in your browser.  Login with an admin account.  From here you can create new pages; you control if and how they appear in the menu system; you can add content; upload pictures; knock yourself out. 2 if you need something more sophisticated you can download and install 'extensions' (Host -> Extensions in the menu) to integrate more functionality into DNN.  There are hundreds of extensions - both free and paid for. 3 if you are a .Net programmer you can create your own custom extensions.  There are tutorials on the net on how to do this. Finally if none of those are enough for you - you may want/need to modify the core code of DNN.  This is the principal reason to use the source packages and your own build.  It's wisest to plug into the overall development efforts for DNN and get your change accepted into the DNN core.  (More information http://www.dnnsoftware.com/community-blog/cid/155105/dnncon-session--contributing-to-open-source-on-github).  If you don't get into the DNN mainstream then you will have created a private fork of the project which is likely to become a pain point for you.  Every time you install a new release of DNN (you WANT to install them for the bug and security fixes) you will have to merge your private changes back into the new version. If your change is half way reasonable it's likely to be acceptable.  If it's not acceptable you will get great advice on how to do what you want *without* the pain of creating a private fork.  Talk before you start coding! RichardHowells Tue, 10 May 2016 08:53:00 GMT f1397696-738c-4295-afcd-943feb885714:87 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/85/DNN-databaseOwner-and-objectQualifier#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=85 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=85&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/85/DNN-databaseOwner-and-objectQualifier SQL Scripts for DNN normally contain a pair of special extra tokens not seen in 'normal' SQL.  For example a CREATE TABLE statement would say: CREATE TABLE {databaseOwner}[{objectQualifier}TABLENAME]... When processed by the SQL processor inside DNN the tokens are replaced with values read from the Web,Config file.  Typical web config values set both to an empty string making the real statement CREATE TABLE [TABLENAME]... If you choose to run DNN SQL in external tools such as Query Manager or SQL Server Management Studio then you must manually edit out the tokens. Why it's done this way In the early days of DNN, web site hosting with SQL server was expensive and often priced per database.  Manipulating the {databaseOwner} and {objectQualifier} values allowed mutiple DNN installations in the same database using different objectQualifier values.  One install could have a family of tables prefixed (say) install01 and another could have a family of tables prefixed (say) install02. RichardHowells Wed, 27 Apr 2016 07:26:00 GMT f1397696-738c-4295-afcd-943feb885714:85 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/78/Setting-up-DNN-on-Amazon-EC2Server-2012SQL-Express-2012#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=78 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=78&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/78/Setting-up-DNN-on-Amazon-EC2Server-2012SQL-Express-2012 These steps worked for me.  I concentrate on stuff that's relevant to EC2 or it being a new machine with an operating system I have never seen before.  Google was a big help. I chose a t2.medium instance.  IMO smaller instances don't have enough memory and burst on demand concept works perfectly for a web site.    1.       Create an instance (outside the scope of this guide)  a.       I chose Windows Server 2012/64bit plus SqlExpress2012  b.      This gives you a pretty virgin install of the Operating System  2.       Start Server Manager  3.       Configure this server  4.       Add the web server role  5.       Add ASP.Net4.5 (and 3.5 if you want it)  a.       the .Net 4.5 feature is already installed but you need to open it up and add ASP.Net 4.5 which is not there at the start.  6.       In Web Server Role – Role Services; add Basic Authentication  7.       Installing that lot takes five minutes or so  8.       Return to server manager (you may be able to do this at the start but I ended up taking a second bite at it) | configure this server  a.       Drill down to Web Server and on to Application Development  b.      Add .Net Extensibility 4.5 (and 3.5 if you want it)  c.       Add ASP.Net 4.5 (and 3.5 if you want it)  9.       Installing them takes another few minutes.  10.   Download DNN to the machine – the enhanced security stuff in IE is a is a pain.  Either tolerate it or turn it off like this  a.        Server Manager | Local Server | Properties | IE Enhanced Security, click the On link and turn it off!  b.      Close & Reopen IE to make it real.  11.   Create a folder for your site and expand the DNN download into it  12.   In IIS Manager create a Site/VirtualDirectory for your site and point it to the web site folder  13.   Set the site to use the .Net 4.5 app pool.  14.   Start SQL Server Management Studio  15.   Add a Login for IIS APPPOOL\.NET v4.5 – you *have* to TYPE this.  You will NOT find it in the Search box  16.   While you are at it, give that account Full Control over the folder your site is going into.  17.   Create a Database for the site to use (Standard DNN process - outside scope of this guide)  a.       allow your new login access to it  b.      give the new login datareader, datawriter, dbowner rights  18.   Modify the site web config to point at your database (Standard DNN process – outside this guide)  19.   Allow Port80 traffic to your instance – this is done by changing the AWS security rules for your instance.  You CANT change the instance to use different rules so you have to change the rules it is using.  20.   Launch IE and browse to your site to install DNN in the traditional way. a.       I cannot say with certainty that it does not work, but I have NEVER managed to make it work when installing from the browser on the instance.  It only worked for me when I browsed to the site from my remote (to the instance) laptop That's it.  The site came up. RichardHowells Tue, 27 Oct 2015 17:38:00 GMT f1397696-738c-4295-afcd-943feb885714:78 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/75/Correcting-a-broken-PortalSettings-table#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=75 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=75&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/75/Correcting-a-broken-PortalSettings-table Symptom.  The site crashes with an exception trace like this one.  (Warning you only see this on web page if the site allows you to see exception messages.  Showing users exception messages is generally a bad security practice.)  You may have to look in the event log table to see this. Server Error in '/' Application. Input string was not in a correct format. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.  Exception Details: System.FormatException: Input string was not in a correct format. Source Error:  An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace:  [FormatException: Input string was not in a correct format.] System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) +10725735 System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) +145 System.String.System.IConvertible.ToInt32(IFormatProvider provider) +46 System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider) +510 DotNetNuke.Collections.CollectionExtensions.ConvertValue(Object value) +100 DotNetNuke.Collections.CollectionExtensions.GetValueOrDefault(IDictionary dictionary, String key, T defaultValue, Func`2 converter) +64 DotNetNuke.Collections.CollectionExtensions.GetValueOrDefault(IDictionary dictionary, String key, T defaultValue) +55 DotNetNuke.Entities.Portals.PortalSettingsController.LoadPortalSettings(PortalSettings portalSettings) +898 DotNetNuke.Entities.Portals.PortalSettings.BuildPortalSettings(Int32 tabId, PortalInfo portal) +28 DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabId, PortalAliasInfo portalAliasInfo) +94 DotNetNuke.HttpModules.UrlRewrite.BasicUrlRewriter.RewriteUrl(Object sender, EventArgs e) +2131 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69     Diagnosis. This huge and scary message may cause you to panic.  Don't.  There are a few useful signals in all that noise. These things... DotNetNuke.Entities.Portals.PortalSettingsController.LoadPortalSettings(PortalSettings portalSettings) +898 DotNetNuke.Entities.Portals.PortalSettings.BuildPortalSettings(Int32 tabId, PortalInfo portal) +28 DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabId, PortalAliasInfo portalAliasInfo) ...appearing in the stack trace make it a reasonable guess that your PortalSettings table contains bad data. The presence of System.Number.ParseInt32 in the stack trace suggests that the code found a PortalSetting that should be an integer but isn't.  There are other reasonably named functions that you may see there with ParseXXXXX in the name.  The XXXXX gives you a clue about what the expected data is. Fixing it. First off take a backup.  You are about to do risky stuff in the database and you need a way to recover if things go wrong and you make the situation worse. Try Sebastian Leupold's excellent Script.  It's intended to correct errors in the PortalSettings table.  https://dnnscript.codeplex.com/releases/view/132975. If the script does not correct your issue then you need to take a very careful look at your PortalSettings table and use your intuition. You'll have to guess a bit. You are looking for a setting (or settings) that sounds like it should be an integer (if ParseInt32 appeared in the stack trace) but is either empty or not an integer. In this context something like 1.0 does *not* qualify as an integer. Once you find some suspect data you need to change it to a 'reasonable' value. Once all the PortalSettings have reasonable values the site should come up again. Leave a comment to let us know how you got on!     RichardHowells Sun, 02 Aug 2015 08:43:00 GMT f1397696-738c-4295-afcd-943feb885714:75 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/74/Speeding-your-DNN-site-with-Client-Side-caching--Part-1#Comments 1 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=74 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=74&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/74/Speeding-your-DNN-site-with-Client-Side-caching--Part-1 Overview The support files used in a web site, especially javascript and css and images, change quite rarely.  Long duration cache headers give a major performance benefit.  DNN's standard tooling automatically provides cache busting parameters.  Cache busters allow site developers freedom to change scripts, css and images.  Those changes can be immediately propagated to the site users.  Download a powershall script to automate setting up cache headers. Details There are only two things you need to know about caching.  "Don’t cache HTML. Cache everything else forever."  Quoted from this article.  You should read it now.  Go on.  I'll wait! The quoted article teaches that controlling cached items needs a sure fire way of using a different url when an item changes.  DNN gives a lot of help in doing that.  Install Fiddler (other great tools exist) to see the url's DNN generates for the different parts of a page. Fiddler monitors all the http traffic from your machine.  A request for this site's home page might look like this... The basic page is roughly 21K bytes.  Then there is near on a megabyte of javascript and CSS required to support the page.  The megabyte of javascript and CSS never (OK rarely) changes.  The web site and the browser already recognize that.  The browser will drop all of the javascript and the CSS into its local cache, just in case.  On a subsequent page request the browser recognizes that there is a copy in the local cache and makes a conditional request for the files.  Essentially it says "I already have a version with 'this date'.  Is that the same version as you would send me?"  If it is the version that the server would send, the server returns a 304 response and does not send the full file content.  It still requires time to round trip the request to the server but saves the time, and bandwidth, of the full data.  In Fiddler it looks like this. When a response comes back with a caching header, it promises the browser that the data at that url will remain valid for the period specified in the header.  For example, in the first image, /Portals/_default/default.css?cdv=73 mentions max-age=31104000 specifying a period of 360 days (in seconds).  Once the browser receives that promise, when *any* page on the site requests the cached url the browser does not contact the server at all.  The file is used directly from the cache.  This is a valuable saving, default.css is used on every page of a DNN site. Note the urls that end in cdv=73. These are generated by DNN.  Some of them come from the basic process of creating a DNN page.  Some come from skin objects such as DnnCssInclude and DnnJsInclude. The parameter on the url is never used by the Web server.   It is purely there to bypass any locally cached browser content with a different parameter value.  Such a parameter is often known as a 'Cache Buster'.  The cdv parameters are supplied by DNN.  They are controlled from Host Settings on the Advanced Settings Tab Note that the 73 reported there is the same as the cdv=73 parameter.  DNN defines a few circumstances that automatically increment the number.  If the automated features don't meet our needs there is a button to increment it manually.  After that increment no client browser will have a copy of the new url and browsers will have to request a full fresh copy.  This technique allows site management to get the benefits of caching; ensure that clients see up to date information; and have a largely fully automated solution. From this we can infer that it should be safe to cache any resource that carries a cdv=* parameter.  We can also infer that it's highly risky to cache a resource that does not carry a cache busting parameter. How to supply cache header information for a file The easiest way is with a small web.config file in the folder.  The location may specify a file – the cache headers are applied to that file only.  The location may specify ‘.’ – the cache headers are applied to any file in that folder.  Such a web.config file looks like this... PowerShell makes it easy I wrote a PowerShell script to make it easy to generate and add the relevant web.config files.  You will need direct access to a command shell on the web server to use it.  Download it from GitHub  (https://github.com/RichardHowells/Dnn.Caching) to a folder on the server.  Open a command prompt and navigate to the folder containing the script.  Type the command powershell –f SetupCachingForDNNSite –webSiteRootFolder "Full path to the root folder of your web site" At the time of writing this will add web.config files to cache: default.css all files in Resources\Libraries all files in js all files in Resources\Shared\Scripts all files in Resources\Shared\Components It will then iterate over every Portal folder in the Portals folder (it skips the *-System folders) it will add a web config file to cache portal.css it will create a CachedFiles folder if there is not one there already; and add a web.config to cache every file in that folder. The intention is that you will manually move your logo image and favicon icon into that folder, changing the site settings to pick them up from that folder.  They will then be automatically cached too. Results After clearing the browser cache every byte of data needs to be retrieved from the server.  This is the worst case and is often referred to as 'cold cache'.  When some, or all, of the data is already in the cache this state is referred to as 'warm cache'.  The process of loading data into the cache is referred to as 'warming the cache'. To retrieve this site's home page: Cache State Requests Approx total bytes Elapsed time  Cold 43 1MB 4 seconds  Warm 3 27KB Under 1 second Clearly the warm cache results are massively better although the cold cache is the worst possible case and real-life performance would be better. Summary - TL;DR; The support files used in a web site, especially javascript and css and images, change quite rarely.  Long duration cache headers give a major performance benefit.  DNN's standard tooling automatically provides cache busting parameters.  Cache busters allow site developers freedom to change scripts, css and images.  Those changes can be immediately propagated to the site users.   Download a powershall script to automate setting up cache headers. RichardHowells Wed, 29 Jul 2015 23:00:00 GMT f1397696-738c-4295-afcd-943feb885714:74 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/72/DotNetNuke-Installs-and-Upgrades-need-to-be-Unblocked-before-Installing#Comments 0 https://www.dynamisys.co.uk/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=723&ModuleID=1621&ArticleID=72 https://www.dynamisys.co.uk:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=72&PortalID=22&TabID=723 https://www.dynamisys.co.uk/Articles-Downloads/Articles/ID/72/DotNetNuke-Installs-and-Upgrades-need-to-be-Unblocked-before-Installing Installs and upgrades to DotNetNuke (DNN), and to DNN modules, are packaged as .zip files.  When a zip file is downloaded to a Windows machine it is often 'blocked' as a security measure.  Before you install; right click on the zip file, choose Properties, and look in the General tab.  At the bottom you may see the text "This file came from another computer and might be blocked to help protect this computer."  If you do see this text click the Unblock button next to it. Using a file that is blocked may result in some of the contained files not being unpacked when the zip file is expanded. RichardHowells Wed, 29 Jul 2015 19:04:00 GMT f1397696-738c-4295-afcd-943feb885714:72